batch: land #8892, #8893, #8894 - #8898

…host several apps

Every class-id-keyed table module init writes — vtables, static methods and
accessors, constructors and flags, the parent map and its dense mirror, names,
lengths, registered ids, bind lengths, the extends-Error / DataView /
typed-array marks, the hasInstance / toStringTag hooks, generic-origin and
fetch-parent maps, anon-shape ids — was a process-global static keyed by a
compile-time class id. Class ids come from a small sequential counter in
codegen, so N dlopen'd copies of one application register the SAME ids with
DIFFERENT func_ptrs (each image's own code addresses) into one HashMap, and
insert is last-writer-wins: after the last image's init every class of every
earlier image dispatched into the last image's code, and only the
last-initialised application worked (#8546). No write order over a shared
table works, so the 21 tables move into one ClassImageTables per image.

A thread resolves its image through a perry_thread_local! handle, falling back
to the process-wide primary image. js_gc_init — codegen's first runtime call in
both `main` and `perry_module_init`, on the thread that runs that image's
module init — enters an image: the first thread to enter owns the primary,
every later one gets a fresh image. perry/thread workers and worker_threads
Workers adopt their spawner's image before running anything, because they never
run module init. A thread that neither entered nor adopted (a pump firing JS
for the primary heap, a reactor thread, a libtest thread) uses the primary,
i.e. the process-global table it saw before, so single-image programs are
unchanged. Each former `static RwLock<..>` is a `static ImageTable<RwLock<..>>`
whose read()/write() return the same guard types, so the call sites are
untouched. Latches and VTABLE_GEN stay process-global on purpose.

Tests: two application threads registering the same class id with different
method addresses each dispatch to their own (sabotage-verified: with the enter
made a no-op the last writer wins and the test fails on the func_ptr); a
spawned worker shares its spawner's image while a second application sees
neither; a thread without an image reads the primary.

Claude-Session: https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd

Claude-Session: https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd

…nctions

`TailCallElimPass::markTails` walks the transitive SSA uses of every alloca;
only loads/stores and nocapture call arguments stop it. On a
statepoint-rewritten function an alloca handed to any runtime call reaches
the statepoint token, its gc.relocates and, through their gc-live bundles,
every later statepoint, so each walk covers the whole function and the pass
costs allocas x uses. Coop's Next.js route (jsonwebtoken's bundled entry:
400 allocas, 643k post-RS4GC instructions, 3.4k statepoints, 477k
relocates; ~1.6M visited uses per alloca) held one LLVM worker for ~100
CPU-minutes in that walk on a unit whose remaining `-Os` passes take ~16 s.

Before the optimization pipeline runs, estimate the walk as
`allocas x instructions` per function and stamp
`"disable-tail-calls"="true"` on any function over the budget (default
2^26; `PERRY_LL_TRE_MAX_ALLOCA_WALK=<n>` raises/lowers it, `0`/`off`
disables). That attribute is TRE's own early-out, so the function keeps
every other pass at the requested level (#8421); it gives up exactly
tail-recursion-to-loop and sibling-call codegen, and it is not `optnone`
(#8583). The trip is logged with the function's name and factors, and the
knob is a build/object cache input.

Fixes #8883

Claude-Session: https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd